Files that changed from the base of the PR and between 563520d and e4b351b.

• api/oc_buffer_settings.c (1 hunks)
• api/oc_main.c (0 hunks)
• include/oc_buffer_settings.h (3 hunks)

• api/oc_main.c

include/oc_buffer_settings.h (8)

24-25: LGTM: Include statement for OC_API macro added.

The addition of #include "oc_export.h" is appropriate as it likely defines the OC_API macro used in the function declarations below. This change aligns with the PR objective of adding OC_API annotations.

---

38-39: LGTM: OC_API annotation added to oc_set_mtu_size.

The addition of the OC_API macro to the oc_set_mtu_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

46-47: LGTM: OC_API annotation added to oc_get_mtu_size.

The addition of the OC_API macro to the oc_get_mtu_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

54-55: LGTM: OC_API annotation added to oc_set_max_app_data_size.

The addition of the OC_API macro to the oc_set_max_app_data_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

62-63: LGTM: OC_API annotation added to oc_get_max_app_data_size.

The addition of the OC_API macro to the oc_get_max_app_data_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

71-72: LGTM: OC_API annotation added to oc_set_min_app_data_size.

The addition of the OC_API macro to the oc_set_min_app_data_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

79-80: LGTM: OC_API annotation added to oc_get_min_app_data_size.

The addition of the OC_API macro to the oc_get_min_app_data_size function declaration is correct and aligns with the PR objective. The function signature remains unchanged, maintaining backwards compatibility.

---

Line range hint 1-93: Overall assessment: Changes look good with a minor improvement needed.

The changes in this file consistently add OC_API annotations to the existing functions, which aligns well with the PR objective. The addition of the new oc_get_block_size function is also good, but it needs documentation to maintain consistency with other functions in the file.

Here's a summary of the changes:

1. Added include for "oc_export.h"
2. Added OC_API annotations to all existing functions
3. Added a new function oc_get_block_size with OC_API annotation

Once the documentation for oc_get_block_size is added, this file will be in excellent shape.

api/oc_buffer_settings.c (4)

30-33: Ensure consistent default MTU size calculation.

In the #else block for OC_INOUT_BUFFER_SIZE, the default _OC_MTU_SIZE is set to 2048 + COAP_MAX_HEADER_SIZE. Verify that this default value aligns with the expected MTU size in the absence of OC_INOUT_BUFFER_SIZE. If 2048 is meant to be a placeholder, consider defining it as a macro or explaining its derivation for clarity.

---

80-94: Ensure correct handling in oc_set_max_app_data_size.

In the function oc_set_max_app_data_size:

• When OC_APP_DATA_BUFFER_SIZE is not defined, _OC_MAX_APP_DATA_SIZE is updated with the provided size.
• If OC_REP_ENCODING_REALLOC is not defined, _OC_MIN_APP_DATA_SIZE is also updated, ensuring consistency between max and min sizes.

Please confirm that this logic accurately reflects the intended behavior, especially in different configuration scenarios.

---

19-24: Include necessary headers for complete functionality.

Ensure that all required headers are included, especially those related to the types used (e.g., size_t) and any external dependencies. For example, if COAP_MAX_HEADER_SIZE is defined elsewhere, verify that its header is included.

Run the following script to check for required includes:

✅ Verification successful

To gather the necessary information, I'll need to examine the contents of the api/oc_buffer_settings.c file and search for any usage of COAP_MAX_HEADER_SIZE. Here's the script to do that:

---

The includes in api/oc_buffer_settings.c are correct and complete.

The file includes all necessary headers for the types and functions it uses. The COAP_MAX_HEADER_SIZE constant is correctly included via "messaging/coap/conf.h" inside a conditional block, which matches its conditional usage in the code. This design choice reduces unnecessary includes when dynamic allocation is not used.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for necessary header files.

# List all include statements.
rg --type c "^#include"

# Search for the definition of COAP_MAX_HEADER_SIZE.
rg --type c "define COAP_MAX_HEADER_SIZE"

Length of output: 246276

---

Script:

#!/bin/bash
# Search for COAP_MAX_HEADER_SIZE usage in api/oc_buffer_settings.c
echo "Searching for COAP_MAX_HEADER_SIZE usage:"
grep -n "COAP_MAX_HEADER_SIZE" api/oc_buffer_settings.c

# Display the contents of api/oc_buffer_settings.c
echo -e "\nContents of api/oc_buffer_settings.c:"
cat api/oc_buffer_settings.c

Length of output: 4587

---

48-71: Validate MTU size adjustment logic in oc_set_mtu_size.

In the function oc_set_mtu_size, there is conditional logic that adjusts _OC_MTU_SIZE and _OC_BLOCK_SIZE based on the provided mtu_size. Please verify:

• The check if (mtu_size < (COAP_MAX_HEADER_SIZE + 16)) ensures the MTU size is sufficient. Confirm that the 16 byte overhead is appropriate.
• The loop calculating _OC_BLOCK_SIZE uses bit shifting to find the highest power of two less than mtu_size. Ensure this correctly derives the desired block size.
• When OC_OSCORE is defined, _OC_MTU_SIZE is adjusted differently. Verify that this aligns with the security requirements.

Run the following script to check for consistent usage of COAP_MAX_HEADER_SIZE and calculations of MTU and block sizes:

✅ Verification successful

MTU Size Adjustment Logic Verified.

• The 16 byte overhead in if (mtu_size < (COAP_MAX_HEADER_SIZE + 16)) is consistently enforced through both compile-time and run-time checks, ensuring compliance with protocol specifications.
• The bit-shifting loop accurately calculates the highest power of two less than mtu_size, correctly determining _OC_BLOCK_SIZE.
• When OC_OSCORE is defined, _OC_MTU_SIZE is appropriately adjusted to include COAP_MAX_HEADER_SIZE, aligning with security requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check calculations of MTU and block sizes.

# Search for all instances where MTU and block sizes are calculated.
rg --type c "_OC_MTU_SIZE|_OC_BLOCK_SIZE|COAP_MAX_HEADER_SIZE"

Length of output: 5253

---

Script:

#!/bin/bash
# Description: Validate the 16-byte overhead and inspect the loop logic in oc_set_mtu_size.

# Find where the 16-byte overhead is defined or used in relation to COAP_MAX_HEADER_SIZE
rg --type c 'COAP_MAX_HEADER_SIZE\s*\+\s*16'

# Extract the implementation of the oc_set_mtu_size function to inspect the loop logic
ast-grep --lang c --pattern $'void oc_set_mtu_size($_) { $$$ }' api/oc_buffer_settings.c

Length of output: 288

---

Script:

#!/bin/bash
# Description: Extract the oc_set_mtu_size function with a flexible pattern and further investigate related calculations.

# Attempt to extract the oc_set_mtu_size function with a relaxed pattern to account for different signatures
ast-grep --lang c --pattern $'void oc_set_mtu_size($_) { $$$ }' api/oc_buffer_settings.c

# If ast-grep fails, use ripgrep to locate the function definition
rg --type c 'void\s+oc_set_mtu_size\s*\(' api/oc_buffer_settings.c

# Investigate the source or documentation for the 16-byte overhead to understand its rationale
rg --type c 'COAP_MAX_HEADER_SIZE\s*\+\s*16' -C 5

# Check definitions related to OC_OSCORE to verify security alignment
rg --type c 'OC_OSCORE' --context 3

Length of output: 49198

---

Script:

#!/bin/bash
# Description: Extract the oc_set_mtu_size function with a flexible pattern and gather detailed context.

# Attempt to extract the oc_set_mtu_size function with a flexible pattern to account for different return types and qualifiers
ast-grep --lang c --pattern $'$_ oc_set_mtu_size($_) { $$$ }' api/oc_buffer_settings.c

# If ast-grep fails, use ripgrep to locate the function definition and extract surrounding lines for context
rg --type c 'oc_set_mtu_size\s*\(' api/oc_buffer_settings.c -A 20 -B 10

# Trace the origin of the 16-byte overhead to understand its rationale
rg --type c 'COAP_MAX_HEADER_SIZE' api/oc_buffer_settings.c port/oc_connectivity.h -C 5

# Inspect the definitions and usages of OC_OSCORE to verify alignment with security requirements
rg --type c 'OC_OSCORE' api/oc_buffer_settings.c port/oc_connectivity.h security/oc_oscore_engine.c security/oc_obt.c security/oc_tls.c

Length of output: 9003

Files that changed from the base of the PR and between e4b351b and be6eb62.

• include/oc_enums.h (5 hunks)
• port/esp32/main/CMakeLists.txt (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj.filters (1 hunks)
• swig/swig_interfaces/oc_buffer_settings.i (1 hunks)
• swig/swig_interfaces/oc_enums.i (1 hunks)

swig/swig_interfaces/oc_buffer_settings.i (2)

25-26: LGTM: OC_API definition added correctly

The addition of #define OC_API before including the oc_buffer_settings.h header is correct and aligns with the PR objective of adding OC_API annotations.

---

Line range hint 18-22: Verify function renames mentioned in the AI summary

The AI summary mentions renaming of 'getMaxAppDataSize' to 'oc_get_max_app_data_size' and 'getBlockSize' to 'oc_get_block_size'. However, the existing renames in the code seem to be in the opposite direction. Please verify if any changes are needed here.

Let's check for any missed renames or inconsistencies:

swig/swig_interfaces/oc_enums.i (1)

35-35: Consider the necessity and impact of OC_API in SWIG interface

The addition of #define OC_API seems to be related to API visibility in the C/C++ code. However, in the context of a SWIG interface file, this definition might not have the intended effect or be necessary.

To ensure this change is consistent with other SWIG interface files and doesn't introduce any issues, please run the following script:

This script will help us understand if OC_API is consistently used across SWIG interfaces and if it's actually used in the oc_enums.h header or other related headers.

✅ Verification successful

OC_API definition is consistent across SWIG interface files

The addition of #define OC_API in swig/swig_interfaces/oc_enums.i aligns with its usage across other SWIG interface and header files. No issues detected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for OC_API usage in other SWIG interface files

# Test 1: Check if OC_API is defined in other SWIG interface files
echo "Checking for OC_API in other SWIG interface files:"
rg --type swig '#define\s+OC_API' swig/

# Test 2: Check if OC_API is used in the oc_enums.h header
echo "Checking for OC_API usage in oc_enums.h:"
rg --type c 'OC_API' include/oc_enums.h

# Test 3: Check if OC_API is used in other header files
echo "Checking for OC_API usage in other header files:"
rg --type c 'OC_API' include/

Length of output: 12247

include/oc_enums.h (5)

30-30: LGTM: Include "oc_export.h" for OC_API macro.

The addition of #include "oc_export.h" is appropriate and necessary for the OC_API macro used in the function declarations below.

---

208-209: LGTM: Add OC_API to oc_enum_to_str function.

The addition of the OC_API macro to the oc_enum_to_str function declaration is correct and aligns with the PR objective. This change appropriately exposes the function as part of the public API.

---

217-218: LGTM: Add OC_API to oc_enum_pos_desc_to_str function.

The addition of the OC_API macro to the oc_enum_pos_desc_to_str function declaration is correct and aligns with the PR objective. This change appropriately exposes the function as part of the public API.

---

226-227: LGTM: Add OC_API to oc_enum_locn_to_str function.

The addition of the OC_API macro to the oc_enum_locn_to_str function declaration is correct and aligns with the PR objective. This change appropriately exposes the function as part of the public API.

---

Line range hint 1-262: Overall assessment: Changes look good and align with PR objectives.

The modifications to include/oc_enums.h consistently add the OC_API macro to the relevant function declarations, which aligns with the PR objective of adding OC_API annotations. These changes appropriately expose the functions as part of the public API, improving their visibility and linkage.

The inclusion of "oc_export.h" is correct and necessary for the OC_API macro definition. All changes are consistent and do not introduce any issues that would prevent merging this PR.

Great job on improving the API visibility of these functions!

port/windows/vs2015/IoTivity-lite.vcxproj (1)

357-357: LGTM: New source file correctly added to the project.

The addition of oc_buffer_settings.c to the project file is correct and aligns with the PR objectives. This ensures that the new functionality related to buffer settings will be compiled and linked properly.

port/windows/vs2015/IoTivity-lite.vcxproj.filters (1)

116-118: LGTM: New file added correctly to the project.

The addition of oc_buffer_settings.c to the project is correct and consistent with the existing structure. It's appropriately placed in the "Core" filter, which aligns with its likely functionality as a core component of the IoTivity-lite project.

To ensure this file exists and is in the correct location, run the following script:

✅ Verification successful

Verification Successful: oc_buffer_settings.c is correctly added to the project.

The file exists in the expected location and is appropriately placed within the "Core" filter. No issues detected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify the existence and location of oc_buffer_settings.c

# Check if the file exists in the expected location
if fd -p "api/oc_buffer_settings.c" ; then
    echo "File oc_buffer_settings.c found in the correct location."
else
    echo "Error: oc_buffer_settings.c not found in the expected location."
fi

# Check if there are any other files with similar names that might have been misnamed
fd -p "oc_buffer_settings.*\.c"

Length of output: 239

Files that changed from the base of the PR and between be6eb62 and 97a24ff.

• api/cloud/oc_cloud.c (1 hunks)
• api/oc_buffer_settings.c (1 hunks)
• api/oc_session_events.c (0 hunks)
• api/plgd/device-provisioning-client/plgd_dps.c (2 hunks)
• api/plgd/device-provisioning-client/plgd_dps_manager.c (0 hunks)
• api/plgd/unittest/plgdtimetest.cpp (0 hunks)
• api/unittest/buffersettingstest.cpp (1 hunks)
• include/oc_network_monitor.h (2 hunks)
• include/oc_session_events.h (2 hunks)
• include/oc_sp.h (2 hunks)
• port/android/ipadapter.c (1 hunks)
• port/esp32/adapter/src/ipadapter.c (1 hunks)
• port/linux/ipadapter.c (1 hunks)
• port/oc_poll_loop.h (2 hunks)
• port/oc_storage.h (2 hunks)
• port/unittest/connectivitytest.cpp (1 hunks)
• port/windows/ipadapter.c (1 hunks)
• swig/swig_interfaces/oc_session_events.i (1 hunks)

• api/oc_session_events.c
• api/plgd/device-provisioning-client/plgd_dps_manager.c
• api/plgd/unittest/plgdtimetest.cpp

• api/oc_buffer_settings.c

include/oc_network_monitor.h (1)

38-38: LGTM: OC_API annotation added correctly

The addition of the OC_API annotation to the oc_add_network_interface_event_callback function is correct and aligns with the PR objective. This clearly marks the function as part of the public API, which is a good practice for API design and documentation.

port/oc_storage.h (4)

24-26: LGTM: New includes added for API annotations

The addition of "oc_export.h" and "util/oc_compiler.h" is appropriate for supporting the new OC_API and OC_NONNULL annotations. This change enhances consistency across the project and prepares the functions for use in the public API.

---

41-42: LGTM: OC_API annotation added to oc_storage_config

The addition of the OC_API annotation to oc_storage_config is appropriate and aligns with the PR objectives. This change clearly marks the function as part of the public API, improving the interface's clarity for users of the library.

---

58-66: LGTM: OC_API and OC_NONNULL added to oc_storage_write

The modifications to oc_storage_write are well-implemented and consistent with the changes made to oc_storage_read:

1. The OC_API annotation correctly marks this function as part of the public API.
2. The OC_NONNULL() attribute enhances safety by enforcing non-null parameters.
3. The updated comments clearly indicate which parameters cannot be NULL.

These changes improve both the usability and safety of the function, maintaining consistency across the API.

---

Line range hint 1-73: Overall assessment: Excellent improvements to API clarity and safety

The changes made to this file consistently enhance the public API by:

1. Adding OC_API annotations to clearly mark public functions.
2. Introducing OC_NONNULL attributes to improve function call safety.
3. Updating comments to provide clearer documentation on parameter constraints.

These modifications align well with the PR objectives and significantly improve the usability and safety of the storage-related functions. The consistent application of these changes across all affected functions is commendable.

port/oc_poll_loop.h (8)

32-32: LGTM: Necessary include for OC_API macro

The addition of #include "oc_export.h" is appropriate and necessary for the OC_API macro used in the new function declarations.

---

42-43: LGTM: Well-defined initialization function

The oc_poll_loop_init function declaration is clear and consistent with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

46-47: LGTM: Clear shutdown function declaration

The oc_poll_loop_shutdown function declaration is appropriate and aligns with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

50-51: LGTM: Well-defined main loop execution function

The oc_poll_loop_run function declaration is clear and consistent with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

54-55: LGTM: Clear signaling function for the main loop

The oc_poll_loop_signal function declaration is appropriate and aligns with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

58-59: LGTM: Well-defined termination function for the main loop

The oc_poll_loop_terminate function declaration is clear and consistent with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

62-63: LGTM: Clear status check function for main loop termination

The oc_poll_loop_is_terminated function declaration is appropriate and aligns with the PR objectives. The OC_API annotation and the brief comment provide good context for its usage.

---

Line range hint 32-63: Overall: Excellent addition of polling loop API

The changes to this file are well-structured and align perfectly with the PR objectives. The new function declarations provide a comprehensive API for managing the polling loop, including initialization, execution, signaling, termination, and status checking. The consistent use of OC_API annotations and the OC_HAS_FEATURE_SIMPLE_MAIN_LOOP feature flag demonstrate good coding practices.

These additions enhance the functionality of the polling loop by providing clear mechanisms for its lifecycle management. The API is well-documented with brief comments, making it easier for developers to understand and use these functions.

api/unittest/buffersettingstest.cpp (1)

1-23: LGTM: Proper file header and includes.

The file starts with an appropriate Apache 2.0 license header and includes the necessary headers for the unit tests.

include/oc_session_events.h (3)

30-30: LGTM: Utility header inclusion

The addition of the "util/oc_compiler.h" header is appropriate. It likely provides necessary compiler-specific macros or utilities for the new functionality introduced in this file.

---

105-115: LGTM: Removal function with proper deprecation notice

The addition of oc_remove_session_event_callback with a clear deprecation notice is well-implemented. The function signature, documentation, and return values are clearly defined.

---

Line range hint 1-133: Overall assessment: Well-implemented API evolution

The changes in this file represent a well-executed evolution of the session events API. The introduction of v1 functions with additional user_data parameters provides more flexibility for users while maintaining backward compatibility through properly deprecated older functions. The consistency between the new add and remove functions is commendable.

Key improvements:

1. Added flexibility with user_data parameter in callback functions.
2. Proper deprecation of older functions.
3. Consistent API design between new functions.
4. Clear documentation of function signatures and return values.

These changes should make the API more versatile and easier to use in various contexts. The minor suggestions for documentation improvements, if implemented, will further enhance the usability of these new functions.

include/oc_sp.h (3)

28-29: LGTM: Include directive for API export definitions.

The addition of the "oc_export.h" include is appropriate. This header likely contains definitions for the OC_API macro used later in the file, which is consistent with the PR objective of adding OC_API annotations.

---

131-133: LGTM: OC_API annotation added to function declaration.

The OC_API macro has been correctly added to the oc_pki_set_security_profile function declaration. This change aligns with the PR objective of adding OC_API annotations to public API functions. The function signature remains unchanged, which preserves backward compatibility.

---

Line range hint 1-141: Overall assessment: Changes are appropriate and align with PR objectives.

The modifications to this file, including the addition of the "oc_export.h" include and the OC_API annotation to the oc_pki_set_security_profile function, are consistent with the PR objective of adding OC_API annotations. These changes improve the API visibility without introducing breaking changes. The implementation is clean and maintains the existing functionality.

api/plgd/device-provisioning-client/plgd_dps.c (2)

33-36: LGTM: Conditional inclusion of network monitoring header

The addition of the conditional compilation directive for including "oc_network_monitor.h" is a good practice. It allows for more flexible compilation based on whether the OC_NETWORK_MONITOR feature is enabled.

---

Line range hint 1-542: Overall assessment: Changes look good

The modifications to conditionally include network monitoring functionality are well-implemented and consistent throughout the file. These changes improve the flexibility of the code by allowing selective compilation of network monitoring features based on the OC_NETWORK_MONITOR macro.

A minor suggestion was made to improve code readability by adding comments to explain empty function bodies when network monitoring is disabled.

api/cloud/oc_cloud.c (1)

43-45: Approve: Good use of conditional compilation for optional feature

The introduction of conditional inclusion for oc_network_monitor.h is a positive change. It allows for more flexible compilation by including the network monitor functionality only when the OC_NETWORK_MONITOR macro is defined. This approach is beneficial for:

1. Reducing compilation time and binary size when the feature is not needed.
2. Allowing easier configuration of builds with or without network monitoring.
3. Improving code modularity by clearly separating optional features.

port/android/ipadapter.c (1)

43-46: Approved: Good use of conditional compilation for optional feature.

The addition of the conditional inclusion for "oc_network_monitor.h" is a good practice. It allows for the network monitoring functionality to be optionally compiled based on the OC_NETWORK_MONITOR macro. This approach helps in managing optional features and keeping the codebase modular.

port/esp32/adapter/src/ipadapter.c (1)

35-38: Appropriate use of conditional compilation

The addition of the conditional include for "oc_network_monitor.h" is well-placed and follows good practices for optional feature inclusion. This change allows for more flexible compilation based on the presence of the network monitoring feature.

Files that changed from the base of the PR and between 97a24ff and 89c88f2.

• api/unittest/buffersettingstest.cpp (1 hunks)
• port/oc_connectivity.h (2 hunks)
• port/oc_connectivity_internal.h (2 hunks)
• port/oc_dns.h (1 hunks)

• api/unittest/buffersettingstest.cpp

port/oc_dns.h (3)

23-33: LGTM: Header guards and includes are well-structured

The header guards, necessary includes, and C++ compatibility handling are all correctly implemented.

Also applies to: 60-64

---

1-64: Overall, the new DNS functionality is well-structured

The introduction of DNS lookup functionality in this header file is well-organized with proper header guards, includes, and conditional compilation. The use of the OC_API macro for function declarations is consistent and appropriate.

Key points:

1. The file structure follows good practices for C header files.
2. Conditional compilation allows for flexible feature inclusion.
3. Function declarations are clear and use appropriate types.

Areas for improvement:

1. Enhance documentation for both functions to provide more context and usage details.
2. Verify the implementation of oc_dns_clear_cache in the corresponding source file.

These improvements will enhance the usability and maintainability of the DNS functionality in the OC framework.

---

48-56: Enhance documentation for oc_dns_clear_cache function and clarify implementation

The function documentation for oc_dns_clear_cache is minimal and could be expanded to provide more context.

Consider enhancing the documentation as follows:

 /**
  * @brief clear the DNS cache
+ *
+ * This function clears the DNS cache, removing all stored DNS resolutions.
+ * It's useful for ensuring fresh DNS lookups or managing memory usage.
+ *
+ * @note This function is only available when OC_DNS_CACHE is defined.
  */

Additionally, the implementation details of this function are not provided in the header file.

Could you clarify where the implementation of this function can be found? It would be helpful to ensure that the implementation exists and matches the intended functionality.

port/oc_connectivity_internal.h (3)

56-63: LGTM: New function oc_send_buffer looks good.

The new function oc_send_buffer is well-documented and consistent with the existing code style. The function signature and return value definitions are clear and appropriate for the task.

---

78-83: LGTM: New function oc_send_discovery_request is appropriately defined.

The new function oc_send_discovery_request is consistent with the existing code style and has an appropriate signature for its purpose. The documentation, while minimal, is sufficient for an internal header file.

---

Line range hint 56-92: Summary: Enhancements to connectivity API look good overall.

The changes to port/oc_connectivity_internal.h introduce two new functions (oc_send_buffer and oc_send_discovery_request) and improve the documentation for oc_connectivity_wakeup. These additions enhance the connectivity API's functionality and clarity. The changes are consistent with the existing code style and conventions, and there are no apparent issues with the implementations.

port/oc_connectivity.h (1)

32-32: LGTM: DNS functionality modularization

The addition of #include "port/oc_dns.h" is a good step towards better code organization. It aligns with the removal of DNS-related functions from this file.

To ensure completeness, please verify that all necessary DNS-related declarations are present in the new oc_dns.h file:

✅ Verification successful

Verification Successful: DNS Declarations Present

The port/oc_dns.h file exists and contains the necessary DNS-related function declarations. The inclusion in port/oc_connectivity.h is correctly handled.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check the contents of the new oc_dns.h file
# Expected: File should exist and contain DNS-related function declarations

cat port/oc_dns.h

Length of output: 1468

Files that changed from the base of the PR and between a9fb620 and fae64b4.

• api/oc_message_buffer.c (1 hunks)
• api/unittest/buffersettingstest.cpp (1 hunks)
• port/oc_connectivity.h (2 hunks)
• port/oc_connectivity_internal.h (4 hunks)
• port/oc_dns.h (1 hunks)
• security/oc_oscore_engine.c (1 hunks)

• api/unittest/buffersettingstest.cpp
• port/oc_connectivity.h
• port/oc_dns.h

port/oc_connectivity_internal.h (2)

57-64: LGTM: New function oc_send_buffer looks good.

The function signature, documentation, and return value definitions are clear and consistent with the file's style. The addition of this function enhances the connectivity functionality as intended.

---

78-83: LGTM: New function oc_send_discovery_request is well-defined.

The function signature and documentation are clear and consistent with the file's style. This addition enhances the discovery functionality within the connectivity module.

api/oc_message_buffer.c (1)

Line range hint 1-214: Ensure thorough testing of network-related functionalities.

Given the change in the connectivity header and the presence of network-related functions in this file (e.g., oc_send_buffer, oc_send_discovery_request), it's crucial to verify that all network operations continue to function correctly.

Please ensure that:

1. All network-related functions used in this file are still accessible and behave as expected.
2. The change doesn't introduce any unintended side effects in the network communication logic.

Consider running comprehensive integration tests that cover:

• Inbound and outbound message handling
• Discovery requests
• Unicast and multicast communication
• Secure communication (if applicable)

This will help catch any potential issues introduced by the header change.

Files that changed from the base of the PR and between 65d0f64 and b28a73a.

• api/oc_mnt.c (1 hunks)
• api/oc_rep_internal.h (1 hunks)
• api/unittest/helperstest.cpp (1 hunks)
• include/oc_rep.h (12 hunks)
• include/oc_signal_event_loop.h (1 hunks)
• messaging/coap/observe.c (1 hunks)

• api/unittest/helperstest.cpp

include/oc_signal_event_loop.h (1)

24-25: LGTM: Appropriate include added for OC_API macro.

The addition of the oc_export.h include is consistent with the use of the OC_API macro later in the file. Good job on placing it in the correct location within the file structure.

api/oc_mnt.c (1)

25-25: Approve the addition of the include directive, but clarification needed.

The addition of #include "api/oc_rep_internal.h" is logically placed and consistent with the AI-generated summary. However, I have a few points for clarification:

1. Could you please explain the necessity of including this header? The existing code doesn't seem to use any new functions from it, so it might be helpful to understand if this is preparation for future changes or resolves some implicit dependencies.

2. The PR title mentions adding OC_API annotations, but this change doesn't directly relate to that. Could you clarify how this include directive contributes to the PR's main objective?

To ensure this include is necessary and not redundant, let's check if oc_rep_internal.h is already indirectly included:

✅ Verification successful

Include directive addition verified.

The #include "api/oc_rep_internal.h" is not included indirectly elsewhere in api/oc_mnt.c, making the explicit addition necessary to ensure the required internal representations are available.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if oc_rep_internal.h is already included indirectly
for header in $(grep -oP '#include "\K[^"]+' api/oc_mnt.c | grep -v 'api/oc_rep_internal.h'); do
  if grep -q '#include "api/oc_rep_internal.h"' "$header" 2>/dev/null; then
    echo "oc_rep_internal.h is already included in $header"
    exit 0
  fi
done
echo "oc_rep_internal.h is not included indirectly"

Length of output: 1775

messaging/coap/observe.c (1)

58-58: Verify the necessity of the new include statement.

The addition of #include "api/oc_rep_internal.h" suggests that functionality from this header is now required. However, there are no visible changes in the rest of the file that directly use this new include.

Could you please verify if this include is necessary for any indirect usage or upcoming changes? If it's not being used, consider removing it to avoid potential confusion and maintain clean dependencies.

To check for any usage of symbols from this header, you can run the following command:

If this command doesn't return any results, it might indicate that the include is not necessary.

✅ Verification successful

The new include statement is necessary.

The addition of #include "api/oc_rep_internal.h" is required as multiple functions prefixed with oc_rep_ are utilized within messaging/coap/observe.c. This ensures that the necessary symbols and functionalities are correctly referenced.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for usage of symbols from oc_rep_internal.h
grep -rn "oc_rep_" messaging/coap/observe.c

Length of output: 1666

include/oc_rep.h (1)

132-132: Addition of OC_API and OC_NONNULL() Annotations Enhances API Safety

The inclusion of OC_API and OC_NONNULL() annotations in the function declarations improves the clarity of the public API and enforces non-null constraints on pointers, enhancing code safety and usability.

Also applies to: 141-141, 151-151, 161-161, 171-171, 184-184, 194-194, 206-206

Files that changed from the base of the PR and between b28a73a and 86e4940.

• api/oc_collection.c (1 hunks)
• api/oc_ri.c (5 hunks)
• api/oc_ri_internal.h (0 hunks)
• api/oc_ri_server.c (2 hunks)
• api/oc_ri_server_internal.h (2 hunks)
• include/oc_ri.h (16 hunks)

• api/oc_ri_internal.h

include/oc_ri.h (6)

Line range hint 40-48: LGTM: Improved comment style consistency.

The change from multi-line to single-line comments for the CoAP methods enumeration improves the overall consistency of the code. The content remains the same, ensuring no loss of information.

---

Line range hint 49-68: LGTM: Improved comment style and added informative note.

The change to single-line comments for resource properties and response status enumerations improves code consistency. The added note about status code translation to HTTP or CoAP is informative and helpful for developers.

---

Line range hint 160-176: LGTM: Consistent comment style for interface masks.

The change to single-line comments for the interface masks enumeration improves the overall consistency of the code. The content remains unchanged, maintaining the same level of information.

---

Line range hint 227-294: LGTM: Consistent comment style for structures and typedefs.

The change to single-line comments for various structures and typedefs improves the overall consistency of the code. The content remains essentially the same, with some minor rewording that doesn't affect the meaning. This change enhances readability without altering functionality.

---

Line range hint 610-627: LGTM: Improved API annotations, documentation, and safety checks.

The changes to oc_ri_get_query_nth_key_value and oc_ri_get_query_value_v1 functions include:

1. Addition of OC_API annotations, indicating they are part of the public API.
2. Updated comments using doxygen-style @param and @return tags, improving documentation clarity.
3. Addition of OC_NONNULL macro, likely enforcing that certain parameters cannot be NULL, which improves function safety.

These changes enhance the API's usability, documentation, and robustness without altering the core functionality.

---

Line range hint 507-516: LGTM: Added OC_API annotations to public functions.

The addition of OC_API annotations to oc_ri_get_app_resource_by_uri and oc_ri_get_app_resources functions indicates that these are part of the public API. This change may affect how these functions are exported or used by consumers of the library, but it doesn't alter the functionality of the code itself.

To ensure this change doesn't introduce any inconsistencies, let's check if other similar functions in the file also have the OC_API annotation:

✅ Verification successful

Verified: OC_API annotations are consistently applied to public functions.

The addition of OC_API annotations to oc_ri_get_app_resource_by_uri and oc_ri_get_app_resources aligns with existing annotations in the file, ensuring these functions are correctly exposed as part of the public API.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other function declarations in the file
grep -n "OC_API" include/oc_ri.h

Length of output: 285

api/oc_collection.c (3)

28-28: LGTM: Include statement added for internal server functionality.

The addition of #include "api/oc_ri_server_internal.h" is appropriate as it likely provides access to internal server-related functions and definitions that may be needed for collection handling. This change appears to be consistent with the file's purpose and existing includes.

---

Line range hint 1-1009: Summary: Minor change with potential for future improvements.

The addition of the include statement for "oc_ri_server_internal.h" is a minor change that doesn't introduce any immediate issues. The file's overall structure and functionality remain intact. However, this new include may provide opportunities for future code improvements or optimizations using the newly available internal server functions. Consider reviewing the usage of this header in the context of the entire file in a future refactoring task.

---

Line range hint 1-1009: Consider reviewing usage of newly included header.

While the addition of the new include statement is appropriate, it may be beneficial to review the contents of "oc_ri_server_internal.h" and consider if any of its newly available functions or definitions could be used to improve or simplify the existing code in this file.

To ensure that the new include is being utilized effectively, you can run the following command to check for any usage of symbols from the newly included header:

✅ Verification successful

Verify Necessity of "oc_ri_server_internal.h" Inclusion

The inclusion of "oc_ri_server_internal.h" in api/oc_collection.c is currently utilized by only one function: oc_ri_URI_is_in_use. If this function is essential and there's no alternative in a more commonly included header, retaining the inclusion is justified. However, if possible, consider refactoring to minimize dependencies by relocating the function or using forward declarations where appropriate.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for usage of symbols from oc_ri_server_internal.h

# Get all function and type names from oc_ri_server_internal.h
header_symbols=$(rg --no-filename '(typedef|struct|enum|union|#define|\w+\s+\w+\s*\()' api/oc_ri_server_internal.h | awk '{print $2}' | cut -d'(' -f1 | sort -u)

# Check for usage of these symbols in the current file
for symbol in $header_symbols; do
  rg "\b$symbol\b" api/oc_collection.c
done

Length of output: 1750

api/oc_ri_server_internal.h (1)

44-45: Ensure consistent use of OC_NONNULL macro

The function oc_ri_URI_is_in_use is annotated with OC_NONNULL(), indicating that certain parameters must not be NULL. Verify that all functions with non-nullable pointer parameters are consistently annotated with OC_NONNULL() to enforce this contract throughout the codebase.

api/oc_ri.c (1)

1304-1307: Validate Parameters for oc_ri_handle_observation()

The updated call to oc_ri_handle_observation() in GET requests correctly handles observation options. However, ensure that all parameters passed to the function are valid and that any potential errors are handled properly.

Run the following script to verify the correctness of parameters used in all calls to oc_ri_handle_observation():

This script searches for all occurrences of oc_ri_handle_observation() in the codebase and displays surrounding lines for context. Review these instances to ensure parameters are correctly used.

Files that changed from the base of the PR and between 86e4940 and 72c27a8.

• api/cloud/unittest/cloud_store_test.cpp (1 hunks)
• api/oc_collection.c (1 hunks)
• api/oc_ri.c (5 hunks)
• api/oc_ri_internal.h (0 hunks)
• api/oc_ri_server.c (2 hunks)
• api/oc_ri_server_internal.h (2 hunks)
• include/oc_ri.h (16 hunks)

• api/oc_ri_internal.h

• api/oc_collection.c
• api/oc_ri_server_internal.h
• include/oc_ri.h

api/cloud/unittest/cloud_store_test.cpp (1)

25-25: LGTM. Verify usage of new include.

The addition of #include "api/oc_rep_internal.h" looks good. However, please ensure that this header is actually used within this test file. If it's not directly used, consider removing it to avoid unnecessary includes.

To verify the usage of the newly added include, you can run the following command:

If this command returns results, it indicates that the include is being used. If not, you may want to reconsider its inclusion.

✅ Verification successful

Verified inclusion of api/oc_rep_internal.h.

The include is actively used in cloud_store_test.cpp, ensuring its necessity.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if oc_rep_internal.h is used in the file

# Test: Search for usage of functions or types from oc_rep_internal.h
rg --type cpp -e 'oc_rep_' -e 'OC_REP_' api/cloud/unittest/cloud_store_test.cpp

Length of output: 2786

api/oc_ri_server.c (2)

20-56: LGTM: New includes and structure definition

The new includes and the oc_resource_defaults_data_t structure definition are well-organized and appropriate for the added functionality.

---

Line range hint 1-694: Overall structure and documentation suggestions

The file structure is generally well-organized, grouping related functions together and using conditional compilation for flexibility. However, there are a few areas that could be improved:

1. Consider adding more detailed function documentation, especially for complex functions like ri_delete_resource and ri_add_observation.

2. There are some TODOs left in the code (e.g., line 516-518). It would be beneficial to address these or convert them into tracked issues if they represent longer-term improvements.

3. The file mixes different levels of abstraction (e.g., low-level memory management with high-level resource handling). Consider if some of these could be separated into different files for better modularity.

To improve the overall architecture and maintainability of the code:

1. Consider creating separate files for different concerns, such as:

   • Resource allocation and deallocation
   • Observation handling
   • ETag management

2. Implement a more robust error handling and logging strategy throughout the file. This could include creating error code enums and using them consistently across functions.

3. Review the use of global variables (e.g., g_app_resources) and consider if some of these could be encapsulated in a context structure for better state management.

To ensure consistent error handling and logging, run the following script:

This script will help identify areas where error handling and logging can be improved for consistency.

api/oc_ri.c (4)

1304-1304: LGTM: Improved observation handling

The modification to oc_ri_handle_observation call with additional parameters enhances the context provided for observation handling. This change appears to be consistent with the updated function signature and improves the overall functionality.

---

327-327: 🛠️ Refactor suggestion

Consider adding error handling for oc_ri_server_init()

The addition of oc_ri_server_init(); is good for initializing server-specific components. However, it's recommended to check the return value and handle any potential errors during the initialization process.

Consider applying this diff to add error handling:

 #ifdef OC_SERVER
-  oc_ri_server_init();
+  if (oc_ri_server_init() != 0) {
+    OC_ERR("Server initialization failed");
+    return;
+  }
 #endif /* OC_SERVER */

Likely invalid or redundant comment.

---

1386-1386: 🛠️ Refactor suggestion

Consider adding error handling for oc_ri_server_shutdown()

The addition of oc_ri_server_shutdown(); ensures proper cleanup of server-specific components. However, it's recommended to check the return value and handle any potential errors during the shutdown process.

Consider applying this diff to add error handling:

 #ifdef OC_SERVER
-  oc_ri_server_shutdown();
+  if (oc_ri_server_shutdown() != 0) {
+    OC_ERR("Server shutdown failed");
+  }
 #endif /* OC_SERVER */

Likely invalid or redundant comment.

---

630-633: 🛠️ Refactor suggestion

Consider checking for state change before notifying observers

The added comment explains the rationale for notifying observers after a PUT/POST request. However, notifying observers for every such request might be inefficient if the resource state hasn't actually changed.

Consider applying this diff to check if the resource has actually changed before notifying observers:

           /* If the recently handled request was a PUT/POST, it conceivably
            * altered the resource state, so attempt to notify all observers
            * of that resource with the change. */
-          oc_ri_notify_resource_observers(ctx.resource, ctx.iface_mask);
+          if (resource_state_changed) {
+            oc_ri_notify_resource_observers(ctx.resource, ctx.iface_mask);
+          }

Ensure that resource_state_changed is set to true only when the resource state is modified.

Likely invalid or redundant comment.

Files that changed from the base of the PR and between 72c27a8 and 66ff75f.

• api/cloud/unittest/cloud_store_test.cpp (1 hunks)
• api/oc_collection.c (1 hunks)
• api/oc_discovery.c (2 hunks)
• api/oc_ri.c (5 hunks)
• api/oc_ri_internal.h (0 hunks)
• api/oc_ri_server.c (2 hunks)
• api/oc_ri_server_internal.h (2 hunks)
• include/oc_ri.h (16 hunks)

• api/oc_ri_internal.h

• api/cloud/unittest/cloud_store_test.cpp
• api/oc_collection.c
• api/oc_ri_server_internal.h
• include/oc_ri.h

api/oc_ri_server.c (3)

20-50: LGTM: New includes and conditional compilation blocks

The added includes and conditional compilation blocks improve code modularity and feature management. This approach allows for better control over enabled features and dependencies.

---

52-56: LGTM: New structure for resource defaults

The oc_resource_defaults_data_t structure is well-defined and appropriate for managing resource defaults. It provides a clean way to associate a resource with its interface mask.

---

Line range hint 1-693: Overall assessment: Significant improvements with some suggestions for enhancement

The changes in this file significantly enhance the resource management and observation handling capabilities of the IoTivity stack. Key improvements include:

1. Better modularization through new includes and conditional compilation.
2. Enhanced resource allocation and management functions.
3. Improved observation handling with support for collections.
4. Addition of ETag support for resources and batches.

While these changes are generally well-implemented, several suggestions have been made to further improve the code:

1. Enhance error handling and logging across various functions.
2. Refactor complex functions for better readability and maintainability.
3. Address TODO comments, particularly in observation handling.
4. Improve consistency in naming conventions and function signatures.
5. Add input validation where appropriate.

Implementing these suggestions will further increase the robustness and maintainability of the code. Great work overall on these improvements!

api/oc_ri.c (1)

630-633: 🛠️ Refactor suggestion

Consider checking for state change before notifying observers

The addition of the comment and the call to oc_ri_notify_resource_observers is good for maintaining consistency after PUT/POST requests. However, notifying observers when the state hasn't changed could lead to unnecessary network traffic.

Consider modifying the code to check if the resource state has actually changed:

           /* If the recently handled request was a PUT/POST, it conceivably
            * altered the resource state, so attempt to notify all observers
            * of that resource with the change. */
-          oc_ri_notify_resource_observers(ctx.resource, ctx.iface_mask);
+          if (resource_state_changed) {
+            oc_ri_notify_resource_observers(ctx.resource, ctx.iface_mask);
+          }

This change assumes you have a way to track if the resource state has changed during the request handling. If not, you might need to implement such a mechanism.

Likely invalid or redundant comment.

Reviewing files that changed from the base of the PR and between 66ff75f and 4cbd9dc.

• api/cloud/oc_cloud.c (1 hunks)
• api/cloud/unittest/cloud_store_test.cpp (1 hunks)
• api/oc_buffer_settings.c (1 hunks)
• api/oc_discovery.c (2 hunks)
• api/oc_helpers.c (4 hunks)
• api/oc_main.c (0 hunks)
• api/oc_session_events.c (0 hunks)
• api/plgd/device-provisioning-client/plgd_dps.c (2 hunks)
• api/plgd/device-provisioning-client/plgd_dps_manager.c (0 hunks)
• api/plgd/unittest/plgdtimetest.cpp (0 hunks)
• api/unittest/buffersettingstest.cpp (1 hunks)
• api/unittest/helperstest.cpp (1 hunks)
• include/oc_buffer_settings.h (3 hunks)
• include/oc_enums.h (5 hunks)
• include/oc_network_monitor.h (2 hunks)
• include/oc_session_events.h (2 hunks)
• include/oc_signal_event_loop.h (1 hunks)
• include/oc_sp.h (2 hunks)
• port/android/ipadapter.c (1 hunks)
• port/esp32/adapter/src/ipadapter.c (1 hunks)
• port/esp32/main/CMakeLists.txt (1 hunks)
• port/linux/ipadapter.c (1 hunks)
• port/oc_connectivity.h (1 hunks)
• port/oc_storage.h (2 hunks)
• port/unittest/connectivitytest.cpp (2 hunks)
• port/windows/ipadapter.c (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj.filters (1 hunks)
• swig/swig_interfaces/oc_buffer_settings.i (1 hunks)
• swig/swig_interfaces/oc_enums.i (1 hunks)

• api/oc_session_events.c
• api/plgd/device-provisioning-client/plgd_dps_manager.c
• api/plgd/unittest/plgdtimetest.cpp
• api/oc_main.c

• api/cloud/oc_cloud.c

• api/cloud/unittest/cloud_store_test.cpp
• api/oc_discovery.c

port/linux/ipadapter.c (6)

43-45: Conditional Inclusion of oc_network_monitor.h

Good job on conditionally including oc_network_monitor.h based on the OC_NETWORK_MONITOR macro. This ensures that the network monitoring features are only included when necessary, improving modularity.

---

Line range hint 67-70: Define ip_interface_t Structure Appropriately

The definition of ip_interface_t is placed within the #ifdef OC_NETWORK_MONITOR block, which is correct. Ensure that any usage of ip_interface_t outside this block is also conditionally compiled to prevent compilation errors when OC_NETWORK_MONITOR is not defined.

---

Line range hint 72-73: Initialize Lists and Memory Pools

The initialization of g_ip_interface_list and g_ip_interface_s using OC_LIST and OC_MEMB macros is appropriate. This allows for efficient management of the ip_interface_t structures.

---

Line range hint 214-216: Ensure Proper Resource Release in oc_network_event_handler_mutex_destroy

You correctly call remove_all_ip_interface() and remove_all_network_interface_cbs() within #ifdef OC_NETWORK_MONITOR. Ensure that any resources allocated when OC_NETWORK_MONITOR is defined are appropriately released here.

---

Line range hint 1066-1083: Resource Cleanup in oc_connectivity_shutdown

In the oc_connectivity_shutdown function, you close sockets and free resources. Recommendations:

• Close All Open File Descriptors: Ensure that all sockets and file descriptors are closed, including any that may have been added in future modifications.
• Mutex Destruction: You correctly destroy the mutex rfds_mutex. Ensure that any other synchronization primitives are also destroyed.

---

Line range hint 1085-1093: Functionality of oc_connectivity_end_session

The function oc_connectivity_end_session appears to loop while oc_connectivity_end_session_v1 returns true. Ensure that this does not lead to an infinite loop in edge cases.

Please confirm that oc_connectivity_end_session_v1 will eventually return false to prevent an infinite loop.

swig/swig_interfaces/oc_buffer_settings.i (1)

25-26: Include Macros for API Visibility and Deprecation

Defining #define OC_API and #define OC_DEPRECATED(...) is appropriate to handle API export definitions and deprecation attributes, especially when generating language bindings with SWIG.

Ensure that these definitions are compatible with those used in the corresponding header files to prevent linkage or compilation issues.

swig/swig_interfaces/oc_enums.i (1)

35-36: Define Macros for API and Non-Null Annotations

Adding #define OC_API and #define OC_NONNULL(...) is appropriate to handle API visibility and non-null annotations in the SWIG interface file.

Make sure these macros align with their usage in the included header files to maintain consistency and prevent compilation warnings or errors.

include/oc_signal_event_loop.h (1)

24-25: LGTM! Changes align with PR objectives.

The addition of the oc_export.h include and OC_API annotation to _oc_signal_event_loop is correct and consistent with the goal of properly marking exported APIs.

Also applies to: 33-33

include/oc_network_monitor.h (1)

38-38: LGTM! API annotations properly added.

The OC_API annotations are correctly added to the network interface event callback functions. Documentation is clear and comprehensive.

Also applies to: 49-49

port/oc_storage.h (1)

24-26: LGTM! Enhanced API safety with proper annotations.

The changes improve the API by:

1. Adding proper export annotations
2. Adding compile-time parameter validation with OC_NONNULL()
3. Clarifying documentation about NULL constraints

Also applies to: 41-41, 52-53, 64-66

include/oc_buffer_settings.h (1)

24-25: LGTM! Required header properly included.

The addition of oc_export.h is necessary for the OC_API annotations.

api/unittest/buffersettingstest.cpp (1)

1-90: LGTM! Well-structured test suite.

The test coverage is comprehensive, testing both dynamic and static allocation scenarios. Good practice to restore initial values after modification.

include/oc_session_events.h (2)

80-91: Good use of deprecation notice.

The deprecation notice clearly indicates the replacement function and version.

---

93-103: Well-documented API enhancement.

The new callback function with user data support improves flexibility while maintaining backward compatibility.

api/oc_buffer_settings.c (2)

41-41: Remove or address the "FIX" comment.

The comment // FIX suggests that this value needs attention. Either justify the value or implement the proper calculation.

---

51-64: Consider validating block size calculation.

The block size calculation uses bit shifting without explicit bounds checking. Consider adding validation to ensure the calculated block size is within acceptable limits.

✅ Verification successful

Block size calculation is properly validated and bounded.

The block size calculation is safe because:

• Input MTU is validated against minimum size (COAP_MAX_HEADER_SIZE + 16)
• Block size is constrained to power-of-2 values through bit shifting
• Block size is bounded by OC_MAX_BLOCK_SIZE which is MTU minus header
• Additional runtime validation exists when used with peer MTU

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential block size validation in other parts of the codebase
rg -A 5 "block.*size.*valid|valid.*block.*size"

Length of output: 65586

---

Script:

#!/bin/bash
# Search for OC_BLOCK_SIZE usage and validation
rg -A 5 "_OC_BLOCK_SIZE|OC_BLOCK_SIZE" 

# Search for block size related constants and limits
rg -A 2 "BLOCK_SIZE|block_size.*max|max.*block_size|block_size.*min|min.*block_size"

# Search for block size validation in test files
fd -e c -e h "test" --exec rg -A 5 "block.*size|_OC_BLOCK_SIZE" {}

Length of output: 76283

include/oc_enums.h (2)

206-207: LGTM! Well-documented enum conversion functions.

The API is clear and follows consistent patterns for string conversion functions.

Also applies to: 215-216, 224-225

---

235-237: Good use of OC_NONNULL annotation.

The OC_NONNULL annotation properly enforces that the oc_defined parameter cannot be NULL.

include/oc_sp.h (1)

28-28: LGTM! Appropriate use of OC_API macro.

The changes correctly expose the oc_pki_set_security_profile function as part of the public API by adding the OC_API macro and including the required header.

Also applies to: 131-131

api/oc_helpers.c (1)

315-315: LGTM! Good use of safer string functions.

The changes from strlen to oc_strnlen improve safety by adding length limits to string operations, preventing buffer overflows.

Also applies to: 355-355

api/unittest/helperstest.cpp (1)

259-341: LGTM! Comprehensive test coverage.

The new test cases provide thorough coverage of the hex string conversion functions:

• Error cases: buffer too small, empty input
• Success cases: even and odd length hex strings
• Edge cases: buffer size checks

api/plgd/device-provisioning-client/plgd_dps.c (3)

33-36: LGTM! Clean header inclusion.

The conditional inclusion of the network monitor header is properly guarded with the OC_NETWORK_MONITOR macro.

---

232-234: LGTM! Clean callback registration.

The network interface event callback registration is properly guarded and follows the initialization pattern.

---

240-242: LGTM! Clean callback deregistration.

The network interface event callback deregistration is properly guarded and ensures proper cleanup.

port/unittest/connectivitytest.cpp (2)

36-39: LGTM! Clean header inclusion.

The conditional inclusion of the network monitor header is properly guarded.

---

Line range hint 163-193: LGTM! Comprehensive test coverage.

The network interface event tests are well-structured and cover:

• Event handler implementation
• Callback registration
• Callback removal
• Failed callback removal
• Event handling

port/windows/vs2015/IoTivity-lite.vcxproj (1)

357-357: LGTM! Clean project file update.

The new source file is properly added to the project.

port/windows/vs2015/IoTivity-lite.vcxproj.filters (1)

116-118: LGTM! Clean filter update.

The new source file is properly added to the Core filter.

port/windows/ipadapter.c (1)

38-40: LGTM: Good use of conditional compilation for optional feature.

The addition of the #ifdef OC_NETWORK_MONITOR directive for including oc_network_monitor.h is a good practice. It allows for conditional compilation of network monitoring features, improving modularity and flexibility of the codebase.

port/android/ipadapter.c (1)

43-45: LGTM: Consistent use of conditional compilation across platform adapters.

The conditional inclusion of oc_network_monitor.h matches the implementation in other adapter files.

port/esp32/adapter/src/ipadapter.c (1)

36-38: LGTM: Consistent use of conditional compilation across platform adapters.

The conditional inclusion of oc_network_monitor.h matches the implementation in other adapter files.

port/esp32/main/CMakeLists.txt (2)

33-33: LGTM: New source file added for buffer settings management.

The addition of ${CMAKE_CURRENT_SOURCE_DIR}/../../../api/oc_buffer_settings.c to the list of source files is appropriate.

🧰 Tools

🪛 GitHub Actions: Static analysis

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: PR #647

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: CMake Windows

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: Create and publish docker images

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

---

33-33: Consider upgrading MbedTLS version.

The pipeline indicates that MbedTLS v3.1.0 is deprecated and support will be removed in a future release.

Run the following script to check the current MbedTLS version configuration:

✅ Verification successful

Confirmed: MbedTLS v3.1.0 is deprecated and should be upgraded.

The codebase currently uses MbedTLS v3.1.0 by default, which is marked as deprecated. You can upgrade to v3.5.0 by setting the CMake option BUILD_MBEDTLS_FORCE_3_5_0=ON. The project already includes the necessary patches for v3.5.0.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check MbedTLS version configuration

# Search for MbedTLS version configuration
rg -l "MBEDTLS.*VERSION" --type cmake

Length of output: 39

---

Script:

#!/bin/bash
# Search for MbedTLS related configurations and dependencies

# Search for mbedtls references (case-insensitive)
echo "=== Searching for mbedtls references ==="
rg -i "mbedtls" --type cmake

# Search for mbedtls in any pipeline or CI configurations
echo -e "\n=== Searching for CI configurations ==="
fd -e yml -e yaml | xargs rg -i "mbedtls" || true

# Search for version requirements or dependencies
echo -e "\n=== Searching for version requirements ==="
fd CMakeLists.txt | xargs rg -i "find_package.*mbedtls|require.*mbedtls"

Length of output: 8967

🧰 Tools

🪛 GitHub Actions: Static analysis

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: PR #647

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: CMake Windows

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

🪛 GitHub Actions: Create and publish docker images

[warning] 33-33: MbedTLS v3.1.0 is deprecated and support will be removed in a future release

Reviewing files that changed from the base of the PR and between 4cbd9dc and 002e89a.

• api/cloud/oc_cloud.c (1 hunks)
• api/cloud/unittest/cloud_store_test.cpp (1 hunks)
• api/oc_buffer_settings.c (1 hunks)
• api/oc_discovery.c (2 hunks)
• api/oc_helpers.c (4 hunks)
• api/oc_main.c (0 hunks)
• api/oc_session_events.c (0 hunks)
• api/plgd/device-provisioning-client/plgd_dps.c (2 hunks)
• api/plgd/device-provisioning-client/plgd_dps_manager.c (0 hunks)
• api/plgd/unittest/plgdtimetest.cpp (0 hunks)
• api/unittest/buffersettingstest.cpp (1 hunks)
• api/unittest/helperstest.cpp (1 hunks)
• include/oc_buffer_settings.h (3 hunks)
• include/oc_enums.h (5 hunks)
• include/oc_network_monitor.h (2 hunks)
• include/oc_session_events.h (2 hunks)
• include/oc_signal_event_loop.h (1 hunks)
• include/oc_sp.h (2 hunks)
• port/android/ipadapter.c (1 hunks)
• port/esp32/adapter/src/ipadapter.c (1 hunks)
• port/esp32/main/CMakeLists.txt (1 hunks)
• port/linux/ipadapter.c (1 hunks)
• port/oc_connectivity.h (1 hunks)
• port/oc_dns.h (1 hunks)
• port/oc_storage.h (2 hunks)
• port/unittest/connectivitytest.cpp (2 hunks)
• port/windows/ipadapter.c (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj (2 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj.filters (2 hunks)
• swig/swig_interfaces/oc_buffer_settings.i (1 hunks)
• swig/swig_interfaces/oc_enums.i (1 hunks)

• api/oc_session_events.c
• api/plgd/device-provisioning-client/plgd_dps_manager.c
• api/plgd/unittest/plgdtimetest.cpp
• api/oc_main.c

• port/esp32/main/CMakeLists.txt
• api/cloud/unittest/cloud_store_test.cpp
• api/cloud/oc_cloud.c
• swig/swig_interfaces/oc_enums.i
• swig/swig_interfaces/oc_buffer_settings.i
• include/oc_signal_event_loop.h
• api/oc_discovery.c
• include/oc_sp.h
• port/windows/vs2015/IoTivity-lite.vcxproj.filters
• api/oc_helpers.c
• port/oc_connectivity.h
• port/windows/ipadapter.c
• port/unittest/connectivitytest.cpp
• include/oc_buffer_settings.h
• port/oc_storage.h
• api/plgd/device-provisioning-client/plgd_dps.c
• port/esp32/adapter/src/ipadapter.c
• include/oc_session_events.h
• include/oc_enums.h

api/oc_buffer_settings.c (4)

35-41: Simplify application data size initialization.

The initialization of _OC_MAX_APP_DATA_SIZE and _OC_MIN_APP_DATA_SIZE has redundancy.

---

41-41: Address the FIX comment for _OC_BLOCK_SIZE.

The line contains a FIX comment that needs to be addressed.

---

69-73: Update return types for consistency.

The getter functions return long while working with size_t variables. This could lead to truncation on some platforms.

Also applies to: 92-96, 108-112, 114-118

---

122-170: Improve error messages for non-dynamic allocation.

The warning messages could be more informative.

port/windows/vs2015/IoTivity-lite.vcxproj (1)

358-358: LGTM!

The buffer settings files are correctly added to the project configuration.

Also applies to: 325-325

api/unittest/helperstest.cpp (2)

311-325: LGTM! The test case is well-designed.

The test effectively verifies the successful conversion path with comprehensive assertions checking both the result code and the converted values.

---

327-341: LGTM! The test case is well-designed.

The test effectively verifies the successful conversion path for odd-length input with comprehensive assertions checking both the result code and the converted values.

port/oc_dns.h (3)

23-30: LGTM!

The include guard and header dependencies are properly organized and follow the project's conventions.

---

1-64: Overall, the header is well-structured and modular.

The header provides a clean API for DNS operations with good separation of concerns through feature flags. While documentation could be enhanced, the implementation follows good practices and maintains compatibility with C++.

---

35-58: Document feature flags and verify dependencies.

Consider adding documentation for the feature flags and their relationships.

Let's verify the feature flag dependencies and documentation:

Add documentation for the feature flags:

+/**
+ * @def OC_DNS_LOOKUP
+ * Enable DNS resolution support
+ */
+
+/**
+ * @def OC_DNS_CACHE
+ * Enable DNS caching support. Requires OC_DNS_LOOKUP to be defined.
+ */
+
 #ifdef OC_DNS_LOOKUP

✅ Verification successful

Documentation improvements needed for feature flags

The feature flags are correctly implemented with proper dependencies, but documentation should be added to explain their purpose:

/**
 * @def OC_DNS_LOOKUP
 * Enable DNS resolution support for converting domain names to IP addresses.
 */

/**
 * @def OC_DNS_CACHE
 * Enable DNS caching to store resolved addresses. Requires OC_DNS_LOOKUP.
 */

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check feature flag documentation and dependencies

# Check if feature flags are documented
echo "Checking for feature flag documentation..."
fd -t f -e h -e c . | xargs rg -l 'OC_DNS_LOOKUP|OC_DNS_CACHE' | while read -r file; do
  echo "=== $file ==="
  rg -A 5 -B 5 'OC_DNS_LOOKUP|OC_DNS_CACHE' "$file"
done

# Check if OC_DNS_CACHE requires OC_DNS_LOOKUP
echo "Checking feature flag dependencies..."
rg '#ifdef\s+OC_DNS_CACHE' -A 2 -B 2

Length of output: 14468

port/linux/ipadapter.c (2)

43-46: LGTM! Clean header inclusion.

The conditional inclusion of the network monitor header is properly implemented with clear preprocessor guards.

---

43-45: ⚠️ Potential issue

Add mutex protection for list operations.

The network interface list operations are not thread-safe. Consider adding mutex protection to prevent race conditions when multiple threads access the interface list.

Let's verify the thread safety concerns:

Also applies to: 46-46

port/android/ipadapter.c (1)

43-45: Apply the same improvements as linux/ipadapter.c.

The same issues regarding thread safety, error handling, and memory management exist in this file. Please refer to the review comments for port/linux/ipadapter.c and apply the same improvements here.

Reviewing files that changed from the base of the PR and between 002e89a and d41d4cd.

• api/cloud/oc_cloud.c (1 hunks)
• api/cloud/unittest/cloud_store_test.cpp (1 hunks)
• api/oc_buffer_settings.c (1 hunks)
• api/oc_discovery.c (2 hunks)
• api/oc_helpers.c (4 hunks)
• api/oc_main.c (0 hunks)
• api/oc_session_events.c (0 hunks)
• api/plgd/device-provisioning-client/plgd_dps.c (2 hunks)
• api/plgd/device-provisioning-client/plgd_dps_manager.c (0 hunks)
• api/plgd/unittest/plgdtimetest.cpp (0 hunks)
• api/unittest/buffersettingstest.cpp (1 hunks)
• api/unittest/helperstest.cpp (1 hunks)
• include/oc_buffer_settings.h (3 hunks)
• include/oc_enums.h (5 hunks)
• include/oc_network_monitor.h (2 hunks)
• include/oc_session_events.h (2 hunks)
• include/oc_signal_event_loop.h (1 hunks)
• include/oc_sp.h (2 hunks)
• port/android/ipadapter.c (1 hunks)
• port/esp32/adapter/src/ipadapter.c (1 hunks)
• port/esp32/main/CMakeLists.txt (1 hunks)
• port/linux/ipadapter.c (1 hunks)
• port/oc_connectivity.h (1 hunks)
• port/oc_dns.h (1 hunks)
• port/oc_storage.h (2 hunks)
• port/unittest/connectivitytest.cpp (2 hunks)
• port/windows/ipadapter.c (1 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj (2 hunks)
• port/windows/vs2015/IoTivity-lite.vcxproj.filters (2 hunks)
• swig/swig_interfaces/oc_buffer_settings.i (1 hunks)
• swig/swig_interfaces/oc_enums.i (1 hunks)
• swig/swig_interfaces/oc_session_events.i (1 hunks)

• api/oc_session_events.c
• api/plgd/device-provisioning-client/plgd_dps_manager.c
• api/plgd/unittest/plgdtimetest.cpp
• api/oc_main.c

• swig/swig_interfaces/oc_session_events.i

• api/cloud/unittest/cloud_store_test.cpp
• api/cloud/oc_cloud.c
• port/esp32/main/CMakeLists.txt
• swig/swig_interfaces/oc_buffer_settings.i
• swig/swig_interfaces/oc_enums.i
• include/oc_sp.h
• api/oc_helpers.c
• port/windows/ipadapter.c
• port/windows/vs2015/IoTivity-lite.vcxproj.filters
• api/oc_discovery.c
• port/oc_connectivity.h
• port/oc_dns.h
• include/oc_signal_event_loop.h
• port/oc_storage.h
• api/plgd/device-provisioning-client/plgd_dps.c
• port/android/ipadapter.c
• include/oc_enums.h
• api/oc_buffer_settings.c
• port/unittest/connectivitytest.cpp
• include/oc_buffer_settings.h
• api/unittest/buffersettingstest.cpp
• include/oc_session_events.h
• port/esp32/adapter/src/ipadapter.c

• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_TSAN_ENABLED=ON -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable, Release, -DOC_DISCOVERY_RESOUR... / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-tsan, -DOC_UBSAN_ENABLED=ON, docker/apps/Dockerfile.dps-cloud-ser... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server-discovery-resource-observable-debug, Debug, -DOC_DISCOVERY_RE... / build-and-push-image
• GitHub Check: plgd-hub-test (cloud-server-asan-access-in-RFOTM, -DOC_ASAN_ENABLED=ON -DOC_RESOURCE_ACCESS_IN_RF... / plgd-hub-test-with-cfg
• GitHub Check: build-and-push-images (cloud-server, Release, docker/apps/Dockerfile.cloud-server) / build-and-push-image
• GitHub Check: plgd-hub-test (dps-cloud-server-faketime-system-time, --set-system-time, -DPLGD_DPS_FAKETIME_ENAB... / plgd-hub-test-with-cfg

port/windows/vs2015/IoTivity-lite.vcxproj (1)

325-325: LGTM! Project configuration updated correctly.

The new files have been properly added to the Visual Studio project:

• Header files: oc_buffer_settings.h and oc_dns.h
• Source file: oc_buffer_settings.c

Also applies to: 358-358

port/linux/ipadapter.c (2)

43-45: Clean and well-structured conditional inclusion.

The conditional inclusion of the network monitor header follows best practices and ensures proper modularization.

---

Line range hint 89-98: Well-structured interface management data structures.

The implementation uses OC_LIST and OC_MEMB macros consistently for memory management, and the structure is clean and focused.

api/unittest/helperstest.cpp (2)

260-270: LGTM! Well-designed error case test.

The test properly validates buffer overflow protection by ensuring the conversion fails when the destination buffer is too small to hold the hex string representation.

---

311-325: LGTM! Comprehensive test for even-length hex string conversion.

The test thoroughly validates the successful conversion path by checking the return code, output length, and the entire content of the output buffer.

include/oc_network_monitor.h (1)

Line range hint 1-53: Verify removal of session event callbacks

The removal of session event callback functions (oc_add_session_event_callback, oc_remove_session_event_callback, etc.) might impact existing code. Let's verify there are no remaining references:

Reviewing files that changed from the base of the PR and between d41d4cd and 1bce387.

• CMakeLists.txt (3 hunks)

CMakeLists.txt (1)

176-187: Well-structured linker-specific optimizations.

The compilation and linking flags are well-chosen and properly documented for both linker types. The mutually exclusive conditions ensure correct flag selection.